1. Field of the Invention
This application relates generally to the field of video game amusement devices including means for processing data in a networked environment. Specifically presented are methods and systems for managing a multiplayer video game on peer-to-peer network connected video game consoles.
2. Description of the Related Art
Many computer video games are programmed to be able to be played with one or more players on a single video game console. In some video games, multiple players can connect multiple consoles together through a phone, cable, or other network. Connecting multiple game consoles together can allow the processing power of each game console, which sometimes houses an extraordinarily powerful central microprocessor, graphics rendering and audio processors, and fast memory, to service the processing needs of each player local to the game console while tying game play of all the consoles into one combined game. For enhanced realism and smooth game play, it is often critical for these networked game consoles to work near the envelope of their processing and memory limits.
There are two common types of network architecture for routing packets and other communication signals among networked game consoles: client-server and peer-to-peer.
FIG. 1 illustrates a “client-server” network architecture. Communications go between each client and the server, but generally not between clients. In one type of client-server architecture, the client computers are often disparate models (e.g. various personal computers or game consoles) to one another that communicate to a central server or set of servers over a wide area network, such as the Internet. In a video game, the central server tracks the location of each player, non-player character, and various items and objects in the video game.
In another type of client-server architecture, the client computers are the same model or relatively similar types (e.g. game consoles) in which one of the clients acts as a server. The server can be selected in an ad hoc fashion between the various connected consoles, and is typically the host player's console, which is the console of the first player to begin the game.
FIG. 2 illustrates a “peer-to-peer” network architecture. Communications typically go between each and every peer. Similar or disparate types of computers can be connected with one another in a peer-to-peer topology. In a video game, the peers pass messages and other communications with one another to duplicate the locations of players, non-player characters, objects, and other settings in each peer.
Multiplayer games can pit different players directly against each other, such as in a shoot-to-kill game. Multiplayer games can also have players cooperate to achieve a desired goal in the game. Cooperative games can involve players in the same platoon in a war simulation, on the same quest in an adventure series, or pursue other exciting missions.
In designing video games, converting a single player game to a multiplayer cooperative game can be difficult because the single player content, such as levels and missions, are typically budgeted for a single player on a console. That is, one player moving around in each room of the world takes up almost all the entire central processing unit (CPU), memory, and streaming budget. To preserve memory, each room is loaded from memory as the player enters it, and the room just left is unloaded. The room and all its features fill the memory of the console.
In a multiplayer game, multiple players can conceivably explore different rooms or levels at the same time. The tight budgeting for the consoles has been worked around by shipping multiplayer cooperative games with a separate set of CO-OP missions with lesser detail than would be available in a non-CO-OP game. Unfortunately, less detail is undesirable, especially when users are accustomed to a high level of detail in the avatars, non-player characters, interactive objects, background, and other visual and audio items in the video game environment from playing the single-player version. Another workaround for multiplayer games is the use of tethering players.
FIGS. 3A and 3B illustrate “tethering” of two players. In an illustrative game with three rooms, A, B, and C, players P1 and P2 are tethered to one another. A solid line around room A denotes that it is loaded in memory, while dashed lines around rooms B and C indicate that they are not loaded. Players P1 and P2 are limited to being within the same room. This limitation is expressed when player P1 stays in room A and player P2 attempts to move from room A to room B (see FIG. 3B). Player P2 is halted from proceeding further until his compatriot follows him.
Tethering the players together preserves memory by forcing the players to move together into each room, so that only one room needs to be loaded and serviced at a time. Thus, the memory and processor budget for the multiplayer game does not significantly exceed that of the single player version of the game.
Tethering players has disadvantages in that one player might want to depart from the confines of the room in which the other player is playing. Thus, solutions for untethering players in a multiplayer game are sought while not requiring an expensive, centralized server for a client-server architecture.
Embodiments of the invention address these and other problems.